Computer-security issues have become increasingly important in the past 20 years. Initially, computer security was addressed by physical securing large computer systems, and by various software-based techniques, including encryption, authorization techniques, and other security measures directed to preventing unauthorized access of secured systems or secured portions of computer systems. However, computer-system developers and computer-science theoreticians have realized that computer systems cannot be made fully secure using such software-based security measures, and physical security is not generally practical in the modern, densely interconnected computing environment.
In order to provide a hardware-level foundation for truly-secured computing, certain modern processor architectures, including the Intel® IA-64 processor architecture provide a number of different hardware privilege levels. The IA-64 processor architecture provides four privilege levels, from the most-privileged privilege level, privilege level 0, to the least-privileged privilege-level, privilege-level 3. Privilege level 0 is intended for execution of operating-system kernels in non-virtualized systems, and for execution of virtual monitors in virtualized computer systems. The intermediate privilege levels are designed for non-kernel operating systems routines and other code needing intermediate privilege levels, and privilege-level 3 is designed for execution of application programs.
In the Intel IA-64 architecture, processor resources, including registers and instructions, are partitioned into privileged and non-privileged resources. Only code executing at the highest privilege level, privilege-level 0, may access privileged processor resources, while code executing any of the four privilege levels may access the unprivileged processor resources. By partitioning processor resources into privileged and unprivileged resources, the Intel IA-64 architecture provides a hardware foundation for securing access to critical machine state from all but those core software routines needed for implementation of operating systems and virtual monitors. In the IA-64 processor architecture, memory resources are associated with privilege levels at the memory-page granularity. The associations are established through privileged instructions that manipulate privileged registers. The IA-64 architecture thus provides a mechanism for partitioning memory into different memory classes accessible to code executing at specified privilege levels. For example, secure memory may be associated with privilege-level 0, for exclusive access by code executing at privilege-level 0.
The IA-64 architecture is not implemented to explicitly support virtualization. Virtualization is a process by which a low-level software construct, referred to as a “virtual monitor,” is introduced directly above the hardware level to provide, along with the hardware, a virtual-machine interface. Virtual-machine interfaces are useful for a number of reasons. First, operating systems can be developed to interface with a virtual-machine interface, rather than to directly interface with a machine interface. Operating systems developed in this fashion can run on any hardware platform on which a virtual monitor providing the virtual-machine interface is resident. Porting a virtual monitor to different hardware platforms, or developing a virtual monitor for a particular hardware platform, is a far less expensive process, in time and engineering resources, than porting an operating system to a particular hardware platform for which the operating system was not initially developed. A second utility provided by virtual monitors is that operating systems designed to assume full control of a machine can be concurrently run on a computer system by the virtual monitor, which multiplexes both processor execution cycles and processor resources between the concurrently running operating systems, much as an operating system multiplexes time and processor cycles between concurrently running processes.
In order to provide a virtual machine interface, the virtual monitor needs to provide to an operating system with the illusion that the operating system has full control of the machine resources, including privileged resources. In particular, the virtual monitor must execute at privilege-level 0 and provide to the operating system the illusion that the operating system is also executing at privilege-level 0, although the privilege-level 0 at which the operating system executes is a virtual privilege-level 0, and not the machine-level privilege-level 0 that only the virtual monitor can execute at. Operating systems assume they have full control of the machine, and that operating system interruption handlers, for example, are directly invoked by hardware, to run at privilege-level 0, on the occurrence of various external interrupts, exceptions, traps, and other events. The virtual monitor must maintain exclusive access to privilege-level 0, however, because the virtual monitor needs to trap, and emulate, attempts by the operating system to execute privileged instructions and to access privileged resources. Otherwise, the virtual monitor would lose control of the hardware, allowing one of several concurrently operating systems to fully appropriate machinery resources, to the detriment of other concurrently running operating systems. Moreover, the virtual monitor must maintain virtual-monitor data securely, or risk corruption and severe corruption-related consequences, such as unrecoverable crashes. The mechanism used by the virtual monitor to detect attempts by operating systems and other code to execute privileged instructions or access privileged resources is to arrange for the operating systems and other code to run at privilege-level 1 or lower, so that when the operating systems or other code attempt to execute a privileged instruction or access a privileged resource, a privileged instruction or privilege-level exception trap is generated, invoking a virtual-monitor interruption handler that can determine how to handle the attempted privileged instruction execution or privileged-resource access, including emulating execution of the privileged-level instruction or access to privileged-resource on behalf of the operating system or other code.
Had the IA-64 processor architecture been developed in order to provide for virtualization, the IA-64 processor architecture would have been designed to insure that no code or process, other than a process or code executing at privilege-level 0, could possibly determine the current privilege level at which the processor code is executing. However, this is not true in the IA-64 processor architecture. There are many ways, referred to as “privilege-level-information leaks,” by which a non-privileged routine can determine the privilege level at which the non-privilege routine is executing. This allows non-privileged code to determine whether or not a virtual monitor is currently managing the computer system and providing a virtual machine interface to the operating system. If an operating system can detect the presence or absence of an underlying virtual monitor, the operating system can take steps to defeat or circumvent the virtual monitor, and to violate the virtual-machine interface established by the virtual monitor. This, obviously, compromises the virtual-machine interface and prevents development of fully secure and sound virtual monitors.
Many ways have been suggested for eliminating the privilege-level-information leaks inherent in the IA-64 architecture. One suggested method is to increase the number of privilege levels by four, to provide additional privilege levels for exclusive use by virtual monitors. In other words, if the 2-bit PSR.cpl field of the processor status register (“PSR”) in the IA-64 architecture were expanded to three bits, eight, rather than four, privilege levels, could be specified. The top four privilege levels could then be used exclusively by the virtual monitor, leaving the four standard privilege levels for operating-system and non-virtual-monitor code. However, this change is not trivial, would require extensive changes to the IA-64 architecture, and would still be transparent to operating systems specifically developed for such an enhanced IA-64 architecture. For this reason, computer-system architects, designers, manufacturers and users have recognized the need for a cost-effective, robust method for preventing privileged-level leaks in the IA-64 architecture, and in similar processor architectures originally designed without an intent for supporting virtualization.